Networked vehicle communications system with front end unit a terminal which can be operated by a user and a corresponding application

ABSTRACT

Networked vehicle communications system with front end unit, terminal which can be operated by a user and associated application. A vehicle communications system having a databus and at least one front end unit which is connected thereto and has a user-interface framework unit, having at least one terminal which can be operated by the user and is connected to the databus, and having at least one functionality which is implemented in the system and can be executed with the participation of the front end unit and of the terminal. The implemented functionality is divided into a part which communicates with the user-interface framework unit and has user-interface ends and into a functional component part which communicates with the user-interface end part on the one hand and with an application framework unit on the other. The user-interface end part is located in one front end unit, while the functional component part is also located there or in another front end unit or in a multi-purpose platform unit which is also connected to the databus.

BACKGROUND AND SUMMARY OF THE INVENTION

This application claims the priority of German Patent Document 199 29331.7, filed Jun. 26, 1999, the disclosure of which is expresslyincorporated by reference herein.

The invention relates to a vehicle communications system having adatabus to which at least one front end unit with user-interfaceframework unit and one terminal which can be operated by the user areconnected, and at least one application, also referred to below asfunctionality, which is implemented in the system and can be executedwith the participation of the front end unit and of the terminals.

In modern motor vehicles, especially cars, numerous functionalities areimplemented which are executed in the dialogue with the system user withthe participation of respectively associated front end units whichinclude associated user interfaces. These functionalities areparticularly numerous telematics applications such as are specified, forexample, in the German Laid-Open Application DE 196 25 002 A1.

In order to be best able to fulfill the resulting requirements, inrecent times consideration has increasingly been given to using what arereferred to as distributed systems, in particular systems which arebased on object-oriented component models. In general electronic dataprocessing, which have relatively high computing capacities incomparison to vehicle applications, techniques for supporting suchdistributed component systems are already customary, for example CORBA(Common Object Request Broker Architecture) and DCOM (DistributedComponent Object Model). However, these techniques cannot be scaled downsatisfactorily to small embedded units. In addition, DCOM is notpresently available for the Windows CE operating system. For vehicle-endconcepts for distributed systems, reference should be made, for example,to the periodical article by K. J. Neumann et al., Ein aufkommenderStandard für verteilte Systeme im Kfz, atp 4/98, page 22, and the olderGerman Patent Application 199 09 157.9 together with the literaturecited there.

The present invention is addressed to providing a solution to the typeof vehicle communications system of the type mentioned at the beginning,which permits, with an unacceptable amount of computing for vehicleapplications, a mechanism for implementing distributed applicationswhich are to be carried out using databus networks which are customaryin vehicles, and in which the application can be kept as independent aspossible of the type of bus system used.

The invention solves this problem by providing a vehicle communicationssystem having a provision for the respective implemented functionalityto be split into a part with user-interface ends and into a part withthe functional components. At least the user-interface end part is partof a front end unit. The functional component part is also located inthe same front end unit or else in another front end unit or in amulti-purpose platform unit which is also connected to the databus. Theuser-interface end part is connected to the user-interface frameworkunit in the respective front end unit, while the functional componentpart is correspondingly connected to an associated application frameworkunit in a communications connection. This system design constitutes amechanism for the implementation of distributed functionalities to beexecuted, in particular also with respect to the subfunctions to beexecuted in that respect, such as display, operator control andinteraction with other applications modules, with an amount of computingwhich is acceptable for vehicle applications.

In a further development of the invention, the respective functionalcomponent part is assigned a virtual terminal unit for communicatingwith the respective terminal which can be operated by the user takesplace through the databus, and which contains the bus-specificimplementation information required for this purpose. As a result, thefunctional components can be kept essentially independent of the type ofdatabus system respectively used so that they do not necessarily need tobe implemented each time another bus type is used.

In one aspect of the system, the functional component part is notlocated in the same unit as the user-interface end part but rather inanother unit which is connected to the databus. The communicationbetween the two parts is then carried out in the form of proxy-stubcommunication via the databus. With this system configuration, theuser-interface ends do not need any knowledge of the distributed systemenvironment currently present but rather they access the assigned proxycomponents which implement the necessary network operations. In theother unit, i.e. a further front end unit or a multi-purpose platformunit which is preferably provided centrally for a plurality of front endunits, the respective stub component functions as a client of thefunctional components and communicates with the associated proxycomponent of the front end unit first mentioned. Because the entirenetwork code is located in the proxy components and the stub components,any application-specific code can be kept completely independent of thedatabus network on which the system is based, without being involved inthe networking, which simplifies its encoding and maintenance.

BRIEF DESCRIPTION OF THE DRAWINGS

Advantageous embodiments of the invention are illustrated in thedrawings and will be described below.

FIG. 1 shows a schematic block diagram of details of a vehiclecommunication system with front end unit and multi-purpose platformunit,

FIG. 2 shows a schematic block diagram of details of a vehiclecommunication system with common implementation of user-interface endpart and functional component part of an application in a front endunit, and

FIG. 3 shows a schematic block diagram of details of a vehiclecommunication system with two front end units and functionalitiesdistributed on the latter.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the first exemplary embodiment shown in FIG. 1, the vehiclecommunications system contains a conventional optical databus 1 of theMOST (Media Oriented System Transport) type, to which a front end unit2, a terminal 3 which can be operated by a user and a multi-purposeplatform unit 4 are connected. Further components of the vehiclecommunications system, in particular further front end units andterminals and vehicle control units which can be operated by a user arenot shown for the sake of clarity. In the system part shown, twoapplications, namely a radio functionality and an address bookfunctionality, are implemented by way of example in order to explain theinvention. The front end unit 2 is specifically a display unit andoperator unit 2 for these functionalities, while the associated terminal3, which can be operated by a user, is an FM tuner which is configuredfor the MOST databus 1.

The respective functionality is characteristically divided in each caseinto a user-interface end part which is implemented in the front endunit 2, and into a functional component part which is implemented in themulti-purpose platform unit 4, i.e. the front end unit 2 includes acomponent 5 with user-interface end parts (UI pages) for the radiofunctionality and a component 6 with user-interface end parts for theaddress book functionality. The multi-purpose platform (MPP) unit 4correspondingly has a functional component part 7 for the radiofunctionality and a functional component part 8 for the address bookfunctionality. The user-interface end parts 5, 6 are connected, in thefront end unit 2, on the one hand to a user-interface framework unit 9which is implemented there, and on the other hand to, in each case, oneassociated proxy component 10, 11. In the MPP unit 4, the functionalcomponent parts 7, 9 are connected on the one hand to an applicationframework unit 12 and on the other hand to associated stub components13, 14. At the bus end, the proxy components and stub components 10, 11,13, 14 are connected to a network service output stage (Most NetServices) 15, 16 which is suitable for the selected bus type MOST andvia which the respective connection to the databus 1 is made.

In addition, a virtual terminal unit 17 is implemented in the MPP unitas a virtual FM tuner. This virtual unit contains the communication ofthe associated functional component part, here of the part 7, for theradio functionality with the specifically used terminal which can beoperated by a user, here the FM tuner 3 which is intended for the MOSTdatabus 1, i.e. the virtual unit 17 effects the communication of itsassociated functional component part 7 with the specific associatedterminal 3 which can be operated by a user, via the existing databus 1,and for this purpose it contains the bus-specific implementation detailsof the functional components. This has the desired consequence that thefunctional components contained in the functional component part 7remain independent of the bus system 1 which is respectively being usedat that time, and therefore does not need to be changed automaticallywhen said bus system 1 changes.

It is known that a distributed system configuration entails a largedegree of complexity, in which case it is recommended that the systemsbe constructed on the highest available layer in the ISO/OSI networklayer model with the layers 1 (physical connection) to 7 (presentationlayer) in order to make as many network details as possible invisibleand to concentrate on the applications requirements of the system. It isprecisely this to which the MOST standard for multimedia applications invehicles is directed. However, MOST is concerned mainly withcommunication between terminals such as CD players, tuners and CDchangers and not with the communication which is desirable between thefront end unit 2 and MPP unit 4 at a higher level.

The proxy-stub communication which is used permits these requirements tobe fulfilled while maintaining the MOST databus 1, the present systemsolution which is provided as a result of this being referred to as aprototype COMOM, see the system description insert in FIG. 1. Thissystem solution makes available a communications function at a highlevel, analogous to the COM/DCOM standard, and in the process uses thecontrol channels and asynchronous channels of the MOST databus 1.Because the interface notation of the prototype COMOM is compatible withCOM-IDL, COMOM can be replaced by DCOM as soon as this technology isavailable for Windows CE. A further alternative is the use of CORBA ifanother operating system is used. CORBA implementations are availablefor important embedded operating systems such as QNX, Chorus, VxWorksinter alia.

According to the system configuration of FIG. 1, the user-interface partof the application is composed of the user-interface ends 5, 6 which areembedded in the user-interface framework unit 9 and communicate with it.In order to resort to the functionality implemented in the respectivefunctional component part 7, 8, the user-interface ends 5, 6 do not needany knowledge on the current distributed system environment. Instead,they access the associated proxy component 10, 11 of the functionalcomponents, which react correspondingly and in the process implement thenecessary network operations. The stub components 13, 14 which arelocated in the MPP unit 4 act as clients of the functional components 7,8 and communicate via the databus 1 with the proxy components 10, 11 atthe front end unit 2 end. The network code which is searched for isstored in the proxy and stub components 10, 11, 13, 14 so that theentire application-specific code can be kept completely independently ofthe databus network 1 which is used as the basis, and does not need tobe involved in the networking, which makes it easier to encode it andmaintain it. The proxy and stub components 10, 11, 13, 14 can beproduced automatically by IDL compilers which are available for COM/DCOMand CORBA products.

As is apparent from the description above, the vehicle communicationssystem can be configured according to the invention in such a way thatcomplete transparency of the distribution over the network is issued forthe components. Whereas given a configuration of FIG. 1, the MPP unit 4preferably functions as a central processing unit which serves aplurality of front end units and a plurality of applications, a furtheradvantage of the invention consists in the fact that a systemconfiguration is also possible without networking, i.e. a system withoutthe functionality of the MPP unit 4 of FIG. 1. A detail of such a systemis illustrated as a second embodiment of the invention in FIG. 2,functionally identical components being provided with the same referencesymbols as in FIG. 1 and reference can in this respect be made to theabove description relating to FIG. 1.

As is apparent from FIG. 2, with this implementation of the system, thecomponents of the MPP unit of FIG. 1 are incorporated in addition to thecomponents of the front end unit 2 of FIG. 1 in a single front end unit2 a which is modified to this extent. As a result, no network code isnecessary for the communication between the user-interface end part 5, 6and the associated functional component part 7, 8 of a respectiveapplication, so that the proxy and stub components 10, 11, 13, 14 of thesystem in FIG. 1 are dispensed with here. In this example, theuser-interface ends 5, 6 communicate directly with the associatedfunctional components 7, 8. This communication can be implemented inturn, for example, via COM/CORBA, see also the system description insertfrom FIG. 2.

A further possible system configuration is illustrated in FIG. 3,functionally identical components being again provided with the samereference symbols as in FIGS. 1 and 2 and in this respect reference canbe made to the above description relating to FIGS. 1 and 2.

As is apparent from FIG. 3, the two exemplary applications (radio,address book) in this implementation are implemented in two front endunits 2 b, 2 c, the one front end unit 2 b of which is of analogousconstruction to the front end unit 2 in FIG. 2 without the functionalcomponent part, while the other front end unit 2 c is configured as astand-alone unit corresponding to the front end unit 2 a from FIG. 2,which front end unit 2 a contains both the respective user-interface endpart 5, 6 and the associated functional component part 7, 8. It is thensufficient to use fewer items of efficient hardware for the front endunit 2 b which is not provided with the functional component part thanfor the other front end unit 2 c on which the functional components arerun.

A number of possible applications which include associated implementedsoftware packages are given below by way of example. An audio packagewhich controls existing audio hardware and routes the respective datafrom audio sources to audio output units can thus be provided. Theassociated audio hardware comprises a central audio output vialoudspeakers and output via headsets which are available on front endunits, under the control of the sound volume and other audio parameters.Vehicle-specific properties, for example setting a currently activeaudio source to a lower sound volume level when a voice outputting unitbecome active, can be implemented in the process.

A telephone application can be used for controlling a GSM functionality,for implementing the TAPI, in particular for voice connections, fordialling telephone numbers, accepting or refusing calls andadministering a call list, and for providing data connections via WAP. Aradio package is provided, as described above, for controlling the tunerhardware such as a MOST-FM tuner, and is expediently configured in sucha way that it provides decoded RDS messages for other services such asTMC and administers presettings and station lists for the installedfront end units. A CD player/video player package controls CD playerhardware which can be composed of a plurality of units, for example a CDchanger and in each case a CD player in a plurality of front end units.The package administers playing lists, generates any desired playinglists and visually displays the current state of the players. Ifpresent, this package can also be responsible for playing video discs.

A vehicle package can be used to provide vehicle information which isavailable on vehicle databuses such as a CAN bus, in that saidinformation is collected and made available via predefined interfaces.This vehicle information can be, for example, information on the speed,the quantity of fuel supplied and various temperature data. Theinformation can he displayed visually and/or made available to otherservices.

A profile package is useful for storing profiles of components, fordetermining components which are affected by a profile change in orderto perform a re-initialization and generate new profiles. The profilesare used to store settings of components and the user interface such ascolours, audio settings etc., and are stored separately in each frontend unlit. A person management package contains functionalities forpersonal information on an identified system user such as a personaladdress book, a calendar, an email function and data synchronizationwith other databases such as other vehicles or a fixed PC system, forexample via the Internet or with Bluetooth technology.

A further package is used to allocate permission for requested useractions and in the process handle in particular conflicts if a pluralityof system users request the same system functionality, but this can onlybe used by one user at the respective time. This package can also beused to restrict seat-related rights of use for specific users, forexample for children, or to administer the profiles for releases andadaptations of rights. A user identification package is responsible forsupplying a user identification to components which require such, suchas an address book, email, calendar etc. The system user must then inputhis identity in a suitable way, for example by means of a PIN, password,fingerprint or retina sensing. A comfort package permitsair-conditioning units and other comfort functions to be controlled, inso far as they are present in the vehicle.

A telematics service package is responsible for collecting generictelematics service information and distributing it to requestingcomponents. An update package administers updates and upgrades ofcomponents and is responsible for running down the system into a statein which updating/upgrading can be carried out, as well as for returningthe system to the normal operating mode. An initialization, monitoringand diagnostics package is responsible for carrying out starting andinitialization procedures, contains the capability of monitoring theoperation of software and hardware components and supports systemdiagnostics.

A supplementary services package can be provided for making availablefunctionalities which are based on conventional system capabilities.These additional functionalities can be, for example, an emergency call,for example automatically when a relatively serious accident is detectedor semi-automatically on user request, in each case in the form oftransmitted data relating to the position of the vehicle or in speechform, a log book function, such as is useful for registering costs forcompany vehicles and for other purposes, as well as antitheft protectionwith which the system can detect, given the presence of a locatingmodule, movement of the vehicle outside specific boundaries and, herenecessary, can stop the vehicle operating.

What is claimed is:
 1. A vehicle communications system comprising: adatabus and at least one front end unit connected to said databus andhaving a user-interface framework unit, at least one terminal which isoperated by the user and is connected to the databus, at least onefunctionality which is implemented in the system and can be executedwith the participation of the at least front end unit and of theterminal, wherein the implemented functionality is divided into a firstpart which communicates with a user-interface framework unit and hasuser-interface ends and into a functional component second part whichcommunicates with both the user-interface end part and with anapplication framework unit, and wherein the user-interface end part islocated in one of the at least one front end unit and the functionalcomponent part is also located in said one front end unit or in anotherone of said at least one front end unit connected to the databus or in amulti-purpose platform unit connected to the databus.
 2. The vehiclecommunications system according to claim 1, wherein the functionalcomponent part is assigned a virtual terminal unit via which thefunctional component part for communicating with the terminal, which canbe operated by the user via the databus is connected, and which containsbus-specific implementation information.
 3. The vehicle communicationssystem according to claim 1, wherein the functional component part islocated in said another one front end unit or the multi-purpose platformunit, and the functional component part is assigned a stub component andthe user-interface end part is assigned a proxy component for thecommunication between the functional component part and theuser-interface end part.